1. Field of the Invention
The invention relates generally to universal serial bus (USB) devices and, more particularly, to USB devices that suspend and resume activities over the USB.
2. Background Information
Over the past 15 years, USB has emerged as the preferred, if not dominant, technology for interfacing personal computers (PCs) or other host systems with a wide variety of USB devices, such as, mass storage, smart phones, digital cameras, media players, modems, keyboards and the like. The devices of interest include multiple, independently controlled, functions, for example, a smart phone may include a camera, media player, and so forth. Users enjoy the convenience and simplicity of being able to attach the multi-function devices to the USB by, for example, plugging into USB ports on the PC or on hubs that, in turn, plug into the USB ports on the PC. Manufacturers and software developers also enjoy the benefits of having a single standard interface to support.
The USB generally operates under host control. The host utilizes class or custom function drivers that are associated with respective functions in the device to communicate with the functions and control transfers of data and requests for attention between the device functions and the host. The host operates in a known manner using the class or function drivers to, at various times as determined by the host, poll the device functions, as appropriate, and move pending data or requests from device hardware that is associated with the function to the host. The device functions determine that, for example, a data transfer to the host has occurred essentially by determining that the data moved from the hardware. The device function may also but not always receive a confirmation from the host. Similarly, the device function determines a data transfer or request from the host to the device has occurred when data are moved to hardware associated with the function.
If the host determines that the bus is essentially inactive, that is, the host determines that it has no data to move to the devices and that the devices have no data or requests to move to the host, the host may suspend one or more portions of the USB bus including the device. Prior to suspending, if the host wants to allow the device to request attention from the host, the host sends a standard command SET_FEATURE(RemoteWakeupEnable) to the device. If the host has no more work to be done, the host then similarly suspends. Later, when the host is ready to exchange is messages with the device, the host resumes one or more portions of the USB bus, including the device.
A given device noticing a suspended bus is required to suspend. Later, if the device needs attention, and if the host previously sent the SET_FEATURE(RemoteWakeupEnable) command, the device may send a “remote wakeup” signal to the host. However, the device is required to wait 3 milliseconds to confirm a suspend; and the host normally stops interrogating the device some time before it actually suspends the bus. If there are data pending to be moved, or written, to the host from one or more functions of the device and/or one or more functions require the attention of the host, the device may attempt to move the data and/or requests to the host during this interval after the host has initiated the suspend operation, but before the device recognizes the suspend. In this case, the device must suspend and then immediately request that the host resume its operations, to attempt to move the pending data and/or requests to the host.
A problem may arise if there are device functions that are not then supported by the host. If the host has never activated or has de-activated one or more of the class or function drivers for one or more functions of the multiple function device, the host will not respond to the device's attempts to move data or requests from the one or more functions. Consider, for example, a device that includes functions associated with push buttons or some other kind of independent behavior. The device function is not privy to whether or not there is an associated class or function driver active at the host. When, a device function autonomously discovers it requires attention from the host, for example, when one of the buttons is pushed, the function places a request for attention at an appropriate function endpoint at the device. If there is no associated class or function driver active on the host, however, the host will not become aware of and respond to the pending request. The request thus remains pending.
The device therefore cannot perform the transactions that prevent the device from suspending or remaining suspended. This creates a “deadlock” situation, in which the device responds to suspend requests by waking the host to handle the pending data and requests, the host again determines that the device has no data to transfer or no is pending requests for attention because there are no active host class or function drivers that allow the host to “see” the pending data or requests at the device, and the host again sends a suspend request, to which the device again responds by waking the host, and so forth. The device therefore remains in or continuously returns to a non-suspended mode, with the device operating at full power consumption, and also, repeatedly waking the host, which also must operate at full power consumption
It is important to note that for USB low-speed, full-speed and high-speed devices, the suspend resume indications over the bus are all device-level operations. There is no standard way for the host to indicate that it is not using a function of a multi-function device; nor is there a way for the host to indicate that it is only interested in wake-up events from a particular subset of functions on a multi-function device.